1. Field of the Invention
The present invention generally relates to data processing. More particularly, embodiments are provided for monitoring variables of a program being debugged.
2. Description of the Related Art
Inherent in any software development technique is the potential for introducing “bugs”. A bug will typically cause unexpected results during the execution of the program. Locating, analyzing, and correcting bugs in a computer program is a process known as “debugging.” Debugging of programs may be done either manually or interactively by a debugging system mediated by a computer system. Manual debugging of a program requires a programmer to manually trace the logic flow of the program and the contents of memory elements, e.g., registers and variables. In the interactive debugging of programs, the program is executed under the control of a monitor program (known as a “debugger”). The debugger may be located on and executed by the same computer system on which the program is executed or may be located on a different system from the one the program is executed on, in the case of a distributed debugger.
Conventional debuggers typically support various operations to assist a computer programmer. Each operation allows the programmer to examine the state of program registers and variables at a given point in the execution of a program. A first operation supported by conventional debuggers is a breakpoint operation. A “breakpoint” is a point in the program where execution of the computer program is stopped so that the state of the program can be examined by a computer programmer. As a result, when a computer program is executed by a debugger, the program executes in a normal fashion until a breakpoint is reached. The debugger then stops execution and displays the results of the computer program to the programmer for analysis.
Most breakpoints supported by conventional debuggers are unconditional, meaning that once such a breakpoint is reached, execution of the program is always halted. Some debuggers also support the use of conditional breakpoints, which only halt execution of a program when a variable used by the program is set to a predetermined value at the time such a breakpoint is reached.
A second operation supported by conventional debuggers is a “step” function. Step functions known in the art include “step through” (also known as “step into”) and “step over” (also known as “next” and “skip”) operations. Step functions permit a computer programmer to process instructions in a computer program at a source file level (i.e., line by line) and at a statement level, and see the results upon completion of each instruction.
Another operation commonly used by programmers debugging code is known as a “run to” operation. “Run to” operations allow a user to execute code until reaching a predetermined point. For example, a first “Run to” operation makes it possible to skip directly to the end of a procedure from a current position in the procedure. A second “run to” operation allows a programmer to determine where execution will be halted according to placement of a cursor.
Typically, step operations, breakpoints and “run to” operations are used together to simplify the debugging process. Specifically, a common debugging operation is to set a breakpoint at the beginning of a desired set of instructions to be analyzed, and then execute the program. Once the breakpoint is reached, the program is halted, and the programmer then steps through the desired set of instructions line by line or statement by statement using the step operation. Alternatively, the programmer may advance to subsequent points in code space using “run to” operations. Consequently, a programmer is able to isolate and analyze a particular set of instructions without having to step through irrelevant portions of a computer program.
One of the primary features of graphical debuggers are windows that contain variables whose values are updated at each and every debugger stop so that a user may see the current value of the variable. Such windows may include a local variables window where all the names and values of the variables that are local to the current procedure are displayed, a monitor window that lists variable names and their values for particular variables selected by the user, and a call stack window.
One problem with such variables windows is that each time the user performs a step, a “run to cursor” or hits a breakpoint, the values of all the variables in these windows must be refreshed. As a result, the system throughput is negatively affected due to the overhead associated with retrieving and displaying the variable values. Particularly in the case of a distributed debugger, this contributes to a substantial performance problem because the data is transported over a communication mechanism, such as a socket.
Therefore, a more efficient variable monitoring method is needed.